Interesting. Never knew Haml does this (but I never used newlines in attributes either). This should be submitted as bug in Haml, too, to see what Nathan thinks about it—while whitespace around HTML nodes is mostly insignificant, content in attributes shouldn't be messed with.

In the meantime I'll still pull this change because it's seems harmless enough. I can't imagine who would want leading whitespace in confirmation messages.

Mislav, thank you. I mentioned this issue to Nathan on Twitter (@nex3) in case he wants to chime in.

One use case I can think of for leading whitespace in messages would be something like

"Here is a list:
    * bullet"

But that seems pretty unlikely, so perhaps this solution is good enough.

If someone wants to heavily style their javascript alert() messages, they're doing it wrong.

This looks like a haml bug for the reasons illustrated below. However, in order to get it to work, you just need to use haml's preserve filter on your confirm message. This fixes the problem:

= button_to("Foo", "/url", :confirm => preserve("Really?\n\nThis cannot be undone."))

Now we don't need to make jquery-ujs forcefully modify attributes on the off-chance that the attribute was mistakenly modified by haml.

To illustrate, it's happening because haml apparently indents the source code after it renders the newlines. So, if you have:

<div>

hi
</div>

Haml then adds two spaces to every nested line inside the div, including blank lines, so you end up with (+ represents a space):

<div>
++
++hi
</div>

Of course your newlines are rendered in the source like:

<div>
<input data-confirm="Really?

This cannot be undone."...
</div>

Which becomes:

<div>
++<input data-confirm="Really?
++
++This cannot be undone."...
</div>

So haml is adding two spaces to every line, even though the one line is both blank and actually in the middle of an attribute's string value. This definitely should be reported as a bug to haml, because it's literally modifying the value of an attribute.

JangoSteve, thank you! I tried find_and_preserve around the helper, but I wasn't aware you could do it the way you describe.

Reported to Haml: https://github.com/nex3/haml/issues/356

And I agree that jquery-ujs shouldn't workaround this now that your preserve solution is known, and the issue has been reported to Haml.

Awesome, I'm sure this would bite me eventually. Glad to hear.

Closing this as wontfix then. Thanks for the research on this, guys